@ioggstream I'm assuming this is a work-in-progress as objects aren't mentioned yet? Also, this will need to apply to any reference-able Object, not just the Schema Object (although handling the Schema Object will give us an OAS-specific way to manage schema media types, so it's extra-valuable there).

@darrelmiller during https://datatracker.ietf.org/doc/minutes-121-httpapi-202411061300/ I understood that 3.0.4 allowed referencing external schemas that do not have the classical structure {paths: {}, components: {}, ..}

Can you please point me to the relevant part of the OAS 3.0.4 spec pls?

@darrelmiller during https://datatracker.ietf.org/doc/minutes-121-httpapi-202411061300/ I understood that 3.0.4 allowed referencing external schemas that do not have the classical structure {paths: {}, components: {}, ..}

Can you please point me to the relevant part of the OAS 3.0.4 spec pls?

@ioggstream Historically, there was nothing explicit in the spec, it's just not forbidden and is commonly used, particularly by tools that split OpenAPI Descriptions into multiple documents for editing, and then combine them back to a single document because many tools don't support multiple documents well (if at all).

It is still not explicitly addressed in 3.0.4, although there is more discussion of the topic of multiple documents in general.

3.1.1 has additional directions regarding parsing as the processing model changed between 3.0 and 3.1. This talks more explicitly about documents without an OpenAPI Object at the root.

Note that everything in 3.0.4 applies to all 3.0.x versions, and 3.1.1 also applies to 3.1.0 – patch releases are essentially updates-with-errata, not distinct versions with their own behaviors.

I'm not convinced of the value of this components parameter but, I don't strongly object. I just don't think anyone is going to be able to use it.

superseeded by #121